Both TwoFactorApiService and TwoFactorService (abstractions and
implementations) pick up:

- New methods deleteTwoFactorYubiKey, deleteTwoFactorDuo,
  deleteTwoFactorEmail, deleteTwoFactorOrganizationDuo, and
  deleteTwoFactorWebAuthnAll routing to the corresponding per-provider
  DELETE endpoints.
- Removal of legacy putTwoFactorDisable and
  putTwoFactorOrganizationDisable (server endpoints are gone).
- Updated return type on getTwoFactorWebAuthnChallenge to the new
  TwoFactorWebAuthnChallengeResponse wrapper.

DefaultTwoFactorApiService spec: legacy put*Disable tests removed,
five new deleteTwoFactor* tests added, WebAuthn challenge test asserts
the new wrapper.

Per-provider setup components (Authenticator, YubiKey, Duo, Email,
WebAuthn) instantiate request models directly, cache the user
verification token from the GET response, and thread it through every
PUT / DELETE / setup-POST call. Each component implements its own
disableMethod against the appropriate per-provider DELETE endpoint:

- Authenticator, YubiKey, Email each call their corresponding
  deleteTwoFactor* method.
- Duo branches on organizationId between deleteTwoFactorDuo and
  deleteTwoFactorOrganizationDuo (the component is shared between
  personal Duo and OrgDuo setup).
- WebAuthn's "Disable All Keys" button calls
  deleteTwoFactorWebAuthnAll (single round-trip; server-side handles
  the wipe atomically). Per-credential remove continues to use
  deleteTwoFactorWebAuthn.
- WebAuthn challenge consumer reads options + userVerificationToken
  from the new wrapper response.

Base setup component disableMethod becomes protected abstract — every
subclass provides its own override. Parent settings page stops
rendering the lapsed-premium-only secondary "Disable" button; the
standard "Manage" button is now enabled for lapsed-premium users on
already-enrolled premium providers, so the same GET → DELETE flow
handles them.

The shared TwoFactorEmailRequest split into purpose-specific models:

- TwoFactorEmailLoginRequest (anonymous login flow, secret-based) drops
  the userVerificationToken field that the server-side login model no
  longer accepts.
- TwoFactorEmailSetupRequest (authenticated setup-send, token-only:
  email + userVerificationToken). postTwoFactorEmailSetup now takes this
  narrower shape instead of the union.

Only PUT responses that re-mint a user-verification token should
overwrite the cached value on the component. Without the guard, a PUT
response with a null token clobbers the live token from the prior GET,
breaking any follow-up DELETE that still runs against the same component
instance.

Matches the existing guard pattern in two-factor-setup-webauthn.component.ts.

Client mirror of the new server response shapes. Adds:

- TwoFactor<Provider>DetailsResponse — five per-provider Details types
  (Authenticator, Duo, Email, WebAuthn, YubiKey) carrying the shared
  provider state used by both GET and Update response wrappers.
- TwoFactor<Provider>UpdateResponse — five per-endpoint PUT responses,
  one per provider, each composing the matching Details type with no
  user-verification token slot.
- TwoFactorOrganizationDuoResponse / TwoFactorOrganizationDuoUpdateResponse —
  split from the user-scoped Duo wrappers so the two scopes can evolve
  independently while sharing the inner TwoFactorDuoDetails.
- TwoFactorWebAuthnDeleteResponse — returned by the per-credential
  WebAuthn DELETE; the updated credentials list travels in the body.

No service-surface or component wiring yet; those land in the next
commits.

…larity

The FIDO2 credential-creation options class previously lived inside
two-factor-web-authn.response.ts under the generic name
ChallengeResponse, which read like it could be any challenge response.
Moves the class to its own file (web-authn-challenge.response.ts) and
renames it to WebAuthnChallengeResponse so its scope is obvious at
every read site.

Touches the 2FA WebAuthn challenge wrapper (TwoFactorWebAuthnChallengeResponse)
and both passkey-login consumers (WebauthnLoginCredentialCreateOptionsResponse,
CredentialCreateOptionsView) to import the renamed type from its new
home.

…response types

Wires the client to the new per-action response shapes. The five
existing TwoFactor<Provider>Response classes are repurposed as the GET
response wrappers — each composes a TwoFactor<Provider>DetailsResponse
plus the freshly-minted user-verification token.

Service surface updated:
- DefaultTwoFactorApiService.getTwoFactor<Provider> returns the GET
  wrapper; put returns the matching *UpdateResponse.
- The six hard-delete methods return Promise<void> and pass
  hasResponse: false to ApiService.send — the matching server endpoints
  now return 204 No Content with no body. deleteTwoFactorWebAuthn
  (per-credential) keeps a body and returns TwoFactorWebAuthnDeleteResponse.
- TwoFactorService pass-through and abstractions updated to match.
- TwoFactorResponse discriminated union updated to reference the
  per-provider GET response classes (plus TwoFactorOrganizationDuoResponse).

Web setup components updated:
- processResponse split into per-action handlers (GET, Update, Delete
  where applicable) so each handler reads from the nested data
  property on its specific response type.
- The runtime `if (response.userVerificationToken)` cache guard from
  PM-38137-prior is dropped — the GET response type now guarantees the
  token non-optionally, and Update/Delete response types carry no token
  slot at all.
- DTO read sites updated from flat (`response.host`) to nested
  (`response.duo.host`) across all five providers.
- The admin-console organization parent setup component is updated for
  the new TwoFactorOrganizationDuoResponse name.

…older

Relocates 2FA request and response model files from the convention folders
(libs/common/src/auth/models/{request,response}/) into the two-factor feature
folder, per the libs/common/src/auth/CLAUDE.md rule that new auth code belongs
in feature folders. Adds request/ and response/ barrels and re-exports them
from the two-factor index. Updates consumer imports across web, cli,
libs/auth, and libs/common.

Leaves identity-two-factor.response.ts (login-flow response, identity-token
group) and web-authn-challenge.response.ts (shared with webauthn-login)
in place to avoid cross-feature coupling.

Renames DeleteTwoFactorAuthenticatorRequest to TwoFactorAuthenticatorDeleteRequest
(file: two-factor-authenticator-delete.request.ts) so the authenticator delete
request matches the TwoFactor<Provider>Delete shape used by the duo, email,
yubikey, web-authn, and organization-duo deletes.

…clearer names

Relocates the 2FA type aliases out of the convention folder
(libs/common/src/auth/types/) and into the two-factor feature folder per the
libs/common/src/auth/CLAUDE.md feature-folder rule. Renames the types so they
describe what they actually are: AuthResponseBase becomes
TwoFactorUserVerificationResult (the master-password/OTP verification proof
threaded into 2FA management request DTOs) and AuthResponse<T> becomes
TwoFactorSetupDialogData<T> (the payload passed as DIALOG_DATA into per-
provider 2FA setup dialogs). Consumers now import from the
@bitwarden/common/auth/two-factor barrel.

…am flow

TwoFactorUserVerificationResult feeds the initial GET / WebAuthn challenge POST
that mints the user-verification token, not the per-provider PUT/DELETE
endpoints — those take the cached UV token string directly. Also clarifies
that TwoFactorSetupDialogData<T> is the return type of TwoFactorVerifyDialog
before being forwarded as DIALOG_DATA to the per-provider setup dialogs.

Extracts TwoFactorUserVerificationResult from two-factor-setup-dialog-data.ts
into two-factor-user-verification-result.ts so each type lives in its own
file. Consumers continue to import from the @bitwarden/common/auth/two-factor
barrel and are unchanged.

…ification-refactor + merge conflicts in 2fa services

Restores relative imports inside the three two-factor API service files
to match the pattern that landed on main. Sibling two-factor service files
were already relative; these three drifted to absolute @bitwarden/common
paths during the refactor.

…nents

Replaces the definite-assignment assertion on the cached
userVerificationToken with an honest string | undefined type and a
requireUserVerificationToken() helper that throws if the field hasn't
been populated yet. Aligns with the typescript-strict ADR (!: is reserved
for required @input properties) and turns a silent undefined-into-request
hazard into an explicit runtime error. The base-class composition refactor
tracked by PM-39385 will eventually eliminate the cached field entirely.

The applyXxxState helpers in the Duo, Email, WebAuthn, and YubiKey setup
components took a TwoFactorXxxDetailsResponse but named the parameter after
the wrapper field (yubiKey, duo, emailData, webAuthn), which made accesses
like yubiKey.key1 read as if poking the wrapper rather than the details.
Renames the parameter to details across all four; the enclosing function
name already establishes which provider it is.

Renames the applyXxxState parameter from details to <provider>Details in
the Duo, Email, WebAuthn, and YubiKey setup components. Trades a few extra
characters per access for clearer reading at the call site
(e.g. yubiKeyDetails.key1 over details.key1).

…nents

The applyXxxState helpers project a per-provider details payload into
local form controls and display flags; "State" misleadingly suggested
writes to the app's state framework. Renames to applyXxxDetails across
authenticator, duo, email, webauthn, and yubikey setup components.

Removes the processUpdateResponse and processDeleteResponse helpers
in the 5 2FA setup components — each body was a single-line wrapper
that called applyXxxDetails(response.xxx). Call sites now apply the
details directly, which makes the unwrap visible inline. The
processGetResponse helper stays because it bundles two coordinated
steps (cache user-verification token + apply details).

Also drops now-unused TwoFactor*UpdateResponse imports in each file.

…le sentences

Each 2FA wrapper response file had a docstring naming the specific server
endpoint that produced it (e.g. \`POST /two-factor/get-authenticator\`),
which breaks the moment the server renames an endpoint. Replaces with
one-sentence descriptions that describe what the response represents —
no endpoint coupling.

Switches the WebAuthn challenge client call from a single-use
SecretVerificationRequest to the new TwoFactorWebAuthnChallengeRequest
carrying the cached user-verification token minted by
getTwoFactorWebAuthn. Drops the now-stale userVerificationToken field
from TwoFactorWebAuthnChallengeResponse — the original token stays
valid through the subsequent PUT. Fixes the passwordless (TDE /
Key Connector) WebAuthn enrollment failure where the second use of
the OTP was rejected.